IBIS Macromodel Task Group

Meeting date: 04 March 2014

Members (asterisk for those attending):
Agilent:                      Fangyi Rao
                            * Radek Biernacki
Altera:                       David Banas
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                            * Brad Brim
                              Kumar Keshavan
                              Ken Willis
Ericsson:                     Anders Ekholm
Intel:                      * Michael Mirmak
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                              Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                              Mike LaBonte
Teraspeed Consulting Group:   Scott McMorrow
                            * Bob Ross

The meeting was led by Bob Ross.

------------------------------------------------------------------------
Opens:

- None


--------------------------
Call for patent disclosure:

- None

-------------
Review of ARs:

- Bob and Ambrish - BIRD 147 editorial work
  - Bob - I'm late on this one.  I don't have draft 7 available to review.
    - Ambrish, could you send me draft 7?
  - Ambrish - yes.
  - Bob - Perhaps we will get some discussion on this later today.

- Walter to send package issues outline and example to the email list.
  - Bob - Walter, is this AR closed?
  - Walter - Yes, it is closed.

- Arpad to make a BIRD163 syntax version of Walter's example.
  - Bob - I believe this is in progress, right?
  - John - I believe so.

-------------
New Discussion:

BIRD 147 Back-channel:

- Bob - Ambrish, are you prepared to continue the back-channel discussion.
- Ambrish - I've received no feedback other than from Bob.
  - Nothing has been updated yet.
  - Nothing new at this time unless others have more comments.
  - I know Walter had noted some concerns in the last meeting.
- Radek - Last time we delayed discussion on one issue.
  - BIRD 147 explicitly uses the AMI_parameters_out change from BIRD 128.
  - BIRD 128 will have to be discussed as well.
  - If any changes are need, they need to be made to both BIRDs.
- Ambrish - What are your concerns for BIRD 128?
- Radek - In its present form, BIRD 147 depends 100 percent on BIRD 128.
  - So we can not ratify BIRD 147 without discussion on BIRD 128.
- Ambrish - Agreed.
- Radek - Personally, I have doubts about whether the solution (BIRD 128) is proper.
  - BIRD 128 is kind of a hack, and we should avoid this type of solution.
  - We should explore other options.
- Walter - One of the problems with alternatives is changing the C function signature.
- Radek - Yes, I know.
  - We added the resolve function and maybe we can add other functions.
  - It is related to version number, so it shouldn't be an issue.
  - There are better solutions to the problem.
- Walter - You understand the functionality we need (BIRD 128).
  - Could you propose an alternative BIRD?
- Radek - If I could find the time.
- Walter - I understand, but I'm serious and want you to submit an alternative solution.
  - I think we should wait for discussion on BIRD 128 until Radek has a proposal.
- Bob - I have one comment on BIRD 147.
  - I'm concerned about the tap coefficient example.
  - We already have a "tap" format, so can't we use that?
- Ambrish - Let me go over your email (it just arrived recently).
- Bob - I didn't mention this issue in the email.
- John - (BIRD 147 comment)
  - Under LFSR format, one of the items is a comma separated list of values.
    - Model makers may put whitespace next to commas.  Could be an issue for parsers.
- Walter - I have a question for clarification on this.
  - In LFSR format, are there always 3 numbers to be comma separated?
- Ambrish - I think there can be more than three.  Those are the taps for the...
- Walter - We need a detailed definition of what that field means.
- Ambrish- I agree.
  - We are working on pseudo code for that.
  - You're the second or third person asking for that clarification.
  - We want pseudo code so that we know bit streams will be identical.
- Walter - Okay, so the document will detail that field.
- John - My point is that if we require that no space be there, people will often do it.
- Ambrish - We can address that.
- Bob - Are these the same meanings as the taps used elsewhere?
- Ambrish - No, these are for the LFSR polynomial.
- Bob - We need to clarify that these taps mean something different than used elsewhere.
- Ambrish - Okay.

Package Modeling Direction:

- Bob - Do we want to continue the discussion on package modeling direction?
- Walter - One of the things I've wanted to do for several weeks is go and review all
           the usage models in the IBIS file for the memory package.
  - Only described the usage model for the first two.
  - Want to go through the others and see if we all agree they should be there.
- Bob - Any comments related to the use model and Walter's questions, or should we wait?
- Randy - Let him review it and see if we have questions.
- Walter - I think it would be useful if you made me presenter.
- Bob - Okay.
- Walter - [sharing the memory_package.ibs file]
  - IO example, one terminal or port on pin and buffer side.
  - Power delivery model.
    - All ports or terminals for power and ground pins.
    - One for each supply signal name (one for each on die voltage).
  - Power deliver model - second method.
    - One port for every power pin, one port for every power port on each buffer.
  - Other flavors of PDN modeling.
    - Model with Die Supply pads.
      - One model goes from all pins to all die pads.
      - Another model goes from all die pads to all buffers.
      - Splits to two models for PDN, one for package and one for die.
      - EDA tool might end up combining them into one model (like the previous example).
- John - I'm not objecting to either.
  - But both are subject to the concern about a large number of nodes for the subckt.
  - Could affect performance on a simulation that doesn't require all of them.
- Walter - This is the way Randy wanted to be able to supply power for his memory.
  - A controller might have 50 times as many, and I agree with you.
- Walter - Another approach, one package model per buffer.
  - One model per buffer/pin, or one per diff pin.
  - Obvious we need to support this.  (this particular example uses s-parameters).
- John - If these aren't s-params, it could be useful to pass a parameter like length.
- Walter - That is my next use case.
  - Subckt instead of s-parameters with parameter passing.
- Walter - I think there is no controversy on the above.
- Walter - One way is to assign an interconnect model to a [Model].
  - So it's a pre-layout solution.
- John - This is useful if packages are identical, or identical "enough" for all DQs.
- Walter - Implies all package models are the same.
  - One could put in typ, min, max to cover the range on that bus.
  - John is right.  Assumption is that all interconnect models on that bus are the same.
- John - Sometimes that's true, sometimes it's not.
  - Is the overhead of supporting a special case worth it?
- Walter - It is definitely worth it.
  - Many vendors are already doing it.
  - SERDES model example from an IBIS member vendor doing it this way.
- Bob - [Model] name could be [Model Selector] name for generality.
- Walter - Correct.
- Walter - One option is one package per [Model] type.
  - This is the only one of interest (i.e., contentious).
  - Example, package model for I/O, one for Differential_I/O, etc.
  - Broadband default model and default differential model could be done with this.
  - Has the advantage of giving us this broadband default capability.
  - One could have different defaults for Input, I/O, etc.
  - Could have coupling or cross-talk, but only for pre-layout usage.
  - For post layout, only uncoupled models.
- Radek - Do you have precedence rules for overlapping applications?
- Walter - Yes, they were outlined in the presentation at Design Con.
  - Hierarchy - per pin name, per [Model] name, per [Model] type.
- Bob - How do we distinguish between differential vs. single-ended output?
- Walter - [Diff Pin] statement tells you what is differential.
  - Here I'm using + and - to indicate which pin is non-inverting and inverting.
- Bob - We have a single ended I/O type and a differential I/O type?
- Walter - Yes, that's a syntax we can come up with.
  - This example model (s4p) applies to diff pins.
- John - The answer to whether we can benefit from having broadband default models is
         that you have vendors who've found it useful?
- Walter - I hate the fact that all we do is default to lumped RLC now.
- John - Some of our reasons for precedence rules are historical.  It adds complexity.
- Brad - Quick question...
  - I look back at what we've got now, RLC instead of broadband.
  - Implicit hierarchy.
  - You've done something analogous here, added hierarchy.
  - All you've done is generalize from lumped RLC to touchstone or IBIS ISS.
  - If it's good to have those levels of abstraction for broadband models, why not have
    it for lumped RLC too?
  - Then you can specify the same format for all and just specify RLC, ISS, touchstone.
- Walter - Yes, that's certainly an enhancement we can make.
- Brad - I'd just like to not have ten different ways to describe this.
- Walter - One thing could simplify it.
  - Instead of saying something is per [Model] type, just make it "default."
  - The reason I put the Input and Output there, it's really a pre-layout issue.
  - It's what Scott wanted - big complex model, here are my near in and far end ports.
  - Could just say the Input and Output are limited to the pre-layout models for Scott.
- Brad - I just wanted to comment on the generality.
- Walter - I totally agree.
- Walter - Lots of stuff in here is because others wanted it.
  - Maybe use "default" and not "[Model] type" at all.
- Walter - We'd be able to parameterize by length.
  - Here's another thing we kind of have and kind of don't have.
  - We have typ, min, max for lumped RLC, but not for everything else.
  - Here I'd like delay corner typ, fast, slow.
  - I think this is a chance to come up with a nice format name.
  - Several format ideas, delay corner, or cross talk, or list, pdf, etc.
  - Need corners of packages for consistency with lumped RLC.
- Radek - Filename can be arbitrary, so those names aren't counted upon, right?
- Walter - Yes.
- Bob - Intent is still to provide typ, min(fast), max(slow)?
- Walter - Notice that I'm not using "corner" here.
  - In AMI and IBIS corner means typ, smallest, largest (values).
  - Package modeling is totally independent of that, so we have to be very careful
    syntactically when we name that.
  - That should be our next step.
- Walter - It's my intention to go to our subcommittee (Randy, Mike, Arpad, Walter).
  - Say to them, "here's what we need to support" and let's work out the syntax.
  - Any objections to that approach?
  - Do we put this in an existing section?
- Bob - Are there any questions?
- Brad - On the delay corner stuff here...
  - What you're talking about is implementing design variation.
  - But is it some discrete or continuous variation?
    - If it's discrete, how many do you allow?
    - If it's continuous, how do you handle that?
    - What you've done is list all the possibilities?  Let the subcommittee sort it out?
- Walter - I listed what I think are important...
  - [sharing "Enhanced Parameter Formats" slide from presentation]
  - Can consider supporting Gaussian, Integer Range, Real Range, pdf, list.
  - If one had DOE experiment for manufacturing distribution, could use these types.
  - Anyone doing DOE and yield prediction would be able to do it with these.
- Brad - So basically the list you're talking about...
  - Then "corner" is a special list with three values.
- Walter - It looks like the parameters in AMI trees.
  - But with a more traditional way of describing the parameters.
- Brad - This is how you might represent what was in the last two lines of your example?
- Walter - Yes, can't do range on s2p, but this could have been a list.
  - Another example had a list that had nothing to do with speed.
- Walter - Traditional IBIS simulation has always had the concept of typ, min, max.
  - As soon as you put in list or Gaussian, that's going to put strain on EDA tools.
  - So, I made sure that for any value there's a way to know the typical value.
  - I.e., for Gaussian it's the mean.
- Brad - One procedural question:
  - Does this larger group want to consider the scope of the generality?
  - Is the subcommittee of four going to make that decision?
- Walter - Subcommittee won't make that decision.
  - We could have straw votes on each one if we wanted to.
- Bob - We might take it to this committee for the straw vote.
  - But people can give the subcommittee some guidance.
  - Rather than come up with defaults, our standard syntax has been that a typical value
    is provided for all cases.
- Bob - Six minutes to go.  Any other comments on your presentation?
- Walter - I'd like to do one quick thing.
  - Work on EMD was using parameter tree structure.
  - One idea was to use it for package modeling, but that has gone by the wayside.
  - Went back and redid an example.  Looks exactly like an EBD file.
  - Added the ability to provide voltages to nets.
  - Added the concept of connections.
  - Instead of a path section in an EBD file, created a [spice description] section.
  - We may decide not to do EBD, EMD at all.
  - Just say in EBD we can now have SPICE descriptions instead.
- Bob - You could just name the things that you need to route.
- Walter - Yes, that's exactly what I did.
  - In the case of I/O, it specified a pull down and ground clamp reference.
  - They were the same, so I only referenced one of the ports.
  - You don't have to provide all 4 voltages to the buffer, maybe just two, for example.
- Walter - In the pin list, is this a signal name or is it POWER and GND?
  - EBD files just have power and ground.
  - Memory chips have multiple power and grounds.
- Randy - EBD syntax doesn't let you provide signal name.
- Walter - This may mean we have to go to EMD.
- Bob - I have a hard cutoff at 4.  Motion to adjourn the meeting. (motion and seconded)
- Bob - Okay, thanks for joining.


AR: Ambrish to update BIRD 147 with Bob.
AR: Mike L. needs to upload versions of BIRD 147.
AR: Subcommittee will work on more package proposals.
-------------
Next meeting: 11 March 2014 12:00pm PT

-------------
IBIS Interconnect SPICE Wish List:

1) Simulator directives
